修复自动分配内存逻辑异常的问题#6356
Conversation
…tings for improved memory management
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 962b0a2252
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (autoMemory) { | ||
| maxMemory = noJVMOptions | ||
| ? null | ||
| : Math.toIntExact(getAutoAllocatedMemory(SystemInfo.getPhysicalMemoryStatus().available()) / 1024L / 1024L); |
There was a problem hiding this comment.
When auto memory is enabled this now derives -Xmx only from current available RAM, ignoring the effective maxMemory value. That value is still used as a required floor elsewhere: the MCBBS post-install task writes manifest.getLaunchInfo().getMinMemory() into maxMemory while preserving the effective auto-memory setting. For a pack that requires e.g. 6 GiB on a machine where the auto heuristic suggests 2 GiB, launch gets the 2 GiB heap and can fail despite the installer recording the modpack's minimum.
Useful? React with 👍 / 👎.
|
|
||
| // 32-bit JVM cannot make use of too much memory. | ||
| if (java.getBits() == Bits.BIT_32 && setting.getMaxMemory() > 1.5 * 1024) { | ||
| if (java.getBits() == Bits.BIT_32 && !setting.getInheritable(GameSettings::autoMemoryProperty) && setting.getMaxMemory() > 1.5 * 1024) { |
There was a problem hiding this comment.
With a 32-bit Java runtime and auto memory enabled, the new auto-memory path can still choose more than the 32-bit heap limit when the machine has several GiB free, but this condition now suppresses the existing warning. In that scenario HMCL proceeds with an oversized -Xmx without telling the user why the launch may fail; the check should use the computed auto allocation rather than skipping auto mode entirely.
Useful? React with 👍 / 👎.
|
由于我怀疑这个设计是故意的，所以追溯（考古）了一下： 当时的 UI 不是现在 radio button 的二选一，而是一个"自动分配"勾选框 + 始终可调的滑动条。选中自动后，滑动条的标签会从"游戏内存"变成"最低分配"： // VersionSettingsPage.java @ 90ee870
label.textProperty().bind(Bindings.createStringBinding(() -> {
if (chkAutoAllocate.isSelected()) {
return i18n("settings.memory.lower_bound"); // "最低分配"
} else {
return i18n("settings.memory"); // "游戏内存"
}
}, chkAutoAllocate.selectedProperty()));对应的 i18n 翻译： # I18N_zh_CN.properties @ 90ee870
settings.memory=游戏内存
settings.memory.lower_bound=最低分配
settings.memory.auto_allocate=自动分配
settings.memory.allocate.auto=最低分配 / 实际分配
settings.memory.allocate.manual=游戏分配在这个设计下， // HMCLGameRepository.java @ 90ee870
public static long getAllocatedMemory(long minimum, long available, boolean auto) {
return auto ? Math.max(minimum, (long) (available * 0.8)) : minimum;
}后来 UI 改成了自动/手动 radio button，选中自动后手动栏变灰（暗示不生效），但 |
2 participants
No description provided.